함께 일한다는 느낌을 주기

새로운 프로젝트를 꾸리면서 구성원이 “함께 일한다”는 느낌을 받을 수 있게 돕는 데에 에너지를 많이 쓰고 있다. 최근에 시도했고, 시도하고 있는 건 두 가지. “잘 했어요”는 아니고 “해보고 있어요”의 의미.

멤버 모두가 참여하는 아키텍처 디자인 워크숍

아키텍처 디자인 워크숍은 김영재 님의 번역서인 ‘개발자에서 아키텍트로’ 라는 책에서 영감을 얻어서 만든 프로그램이다.

2주간 팀 멤버가 모두 참여해서, 비즈니스 목표, 프로젝트 환경, 요구사항, 해결해야 할 문제와 기대하는 수준을 확인하고, 문제를 해결하는 아키텍처를 함께 디자인했다. 나도 처음 해보는 거라 걱정이 많았는데 아키텍처의 태생이 그러하듯 “완벽해”라는 말은 할 수 없지만(그게 이 프로그램의 목표도 아니고), 팀이 일을 시작할 수 있는 수준의 충분한 합의를 만들었다는 걸로 만족스럽다.

사실 멤버 모두가 참여하는 이런 회의 방식은 효율이 좋지 않다. 각자의 지식수준이 달라서 모두가 같은 수준으로 시스템을 이해하고 의견을 제시하기는 애초에 어렵다. 미팅에 참여하는 인원이 많으면 덩달아 커뮤니케이션 비용도 높아진다. 그럼에도 모두가 소중하게 여겨야 할 큰 합의는, 같이 결정하는 게 효과적이라고 생각했다. 최소한 “우리가 같이 만들었다”라는 느낌은 주고 싶었다. 모르는 걸 같이 배울 수 있는 기회이기도 했고. 그래서 비효율을 감수했다. 멤버가 8명이라 부담이 조금 덜했던 건 다행. 인원이 더 많았다면 깊게 고민했을 거 같다.

아키텍처라는 건 구성원이 만든 합의인데, 일부가 밀실에서 규칙을 만들고 “이제 우리 모두 이걸 따르자!”라고 선언하는 방식은 합의가 제대로 지켜질 가능성을 낮춘다. 규칙의 의미를 이해하지 못하고 그저 따라가기에 급급하면 변화에 대응하기 어렵다. 규칙이 있다는 걸 몰라서 따를 수 없다면 그건 더 문제고.

규칙을 만드는 소수가 문제를 제대로 이해하고 있지 못할 가능성도 배제하기 어렵다. 아키텍처는 자신이 놓일 환경의 여러 요소에 영향을 받는다. 그렇다면 관련 지식을 가진 모두가 자신이 가진 지식의 조각을 함께 맞춰야 문제를 제대로 이해할 수 있지 않을까? 속도만 좇다가 엉뚱한 산에 올라가느니, 조금 느리더라도 목표를 함께, 잘 찾아가는 과정을 팀이 경험할 수 있는 계기를 만들어 주는 게 중요했다.

약간의 비효율이 존재하더라도 합의를 만든다는 본질에 충실하고 싶었는데, 동료의 진솔한 피드백은 다음 주에 1 대 1 스몰토크를 하면서 수집할 생각.

태스크 담당자와 짝꿍을 1명 이상 연결하기

풀기 어려운 문제를 혼자 해결해야 할 때 느낄 수 있는 감정 중에 하나는 외로움인 것 같다. 나만 그런가?

앞으로 팀이 풀어야 할 문제는 지금까지 해보지 않은 프랙티스를 많이 도입해야 한다. 가보지 않은 길이라는 건, 그만큼 어렵다는 뜻이고, 주니어 비중이 높은 우리 팀 구성상 혼자 문제를 풀도록 놔두면 외로움이라는 감정과 싸우는 데에 소모하는 에너지가 클 수밖에 없다. 실제로 이런 이야기를 듣기도 했고.

역시나 약간의 비효율이 존재하더라도 혼자 문제를 잡고 끙끙하게 두지 않기로 했다. 일단 백로그를 리뷰하면서 각자 자신이 풀고 싶은 문제를 선택한다. 이때 개별 태스크의 담당자를 한 명으로 한정하지 않는다. 같은 문제를 풀고 싶은 사람이 자연스레 2명 또는 3명이 되는데, 가능한 모두가 기회를 갖는다. 물론 어디까지나 개인의 선택.

하지만 팀 여건상 담당자를 여러 명 배정할 수 없는 상황이 생기는데 이럴 때는 메인 담당자를 두고 다른 사람은 고민을 도와주는 짝꿍으로 티켓에 명시했다. 짝꿍의 역할은, “나도 이 문제에 관심이 있어. 도움이 필요하면 나한테 말해. 혹시 내 일이 빨리 끝나면 도와줄게” 정도일 것 같다.

잘 동작할지, 어떤 심리적 장벽이 또 작용할지, 엉망진창이 될지 솔직히 나도 잘 모르겠다. 잘 안 되면 그때 다른 길을 찾지 뭐, 이런 생각.

다만 이 프로젝트의 끝에 구성원 모두가 이런 생각을 할 수 있으면 참 좋겠고 그걸 돕는 게 내 역할이라고 생각 중.

“오, 우리가 이걸 했다고?”